As computer networks become more prevalent in all facets of industry and enterprise, users more frequently need to access resources that are located on a computer that is remote from their own machine. However, the possibility of remote users accessing local data raises many security concerns. For example, a remote user may access data that they are not authorized to access, and may even maliciously destroy or alter such data. Accordingly, most network domains require that users login and be authenticated prior to gaining access to resources in that domain. Authentication is intended to ensure that the identity and associated permissions of the user are known prior to granting access. The process of authentication entails checking whether access is appropriate and then either granting or denying access based on the results of that check.
As used herein, a principal is an entity (typically a human, computer, application, or service) that attempts to access a secured resource or facility (e.g. an application). Authentication is the process of proving or verifying identity. An authority is a trusted entity that is used to provide authentication services with respect to some set of principals.
For a given authority, it trusts principals once it has authenticated them, but it may not trust other authorities to have properly authenticated its principals. For this reason, a name space convention has developed whereby particular authorities authenticate only those principals whose account ID resides in a given name space. In particular, the account ID usually comprises at least a user identifier portion and an authenticating authority portion. The authenticating authority portion of the account ID identifies the namespace of the principal ID, and hence the authority that should authenticate the principal. The principal identifier portion usually identifies the particular user as distinct from other users within the same name space. Thus, for example, the account ID bob@dev.microsoft.com should be authenticated by the authority for the domain dev.microsoft.com, whereas the account ID bob@mktg.microsoft.com should be authenticated by the authority for the domain mktg.microsoft.com.
This solution has allowed a certain amount of security with respect to network resources; however the static nature of the name space divisions creates additional problems. For example, when a user moves from one domain to another or is required to have access across domain boundaries the present system is not easily accommodating. In the former case, the user is required to obtain a new account ID that identifies the namespace of the new domain rather than the old domain, while in the latter case the user must either obtain an additional account in the proper namespace or there must exist strong administrative confidence (e.g. trust) between authorities.